• x/perp/v2/types/tx.pb.go

• CHANGELOG.md (1 hunks)
• app/app.go (1 hunks)
• proto/nibiru/perp/v2/tx.proto (2 hunks)
• wasmbinding/exec_perp_test.go (3 hunks)
• wasmbinding/message_plugin.go (3 hunks)
• wasmbinding/wasm.go (2 hunks)
• x/perp/v2/integration/action/market.go (2 hunks)
• x/perp/v2/keeper/amm_test.go (4 hunks)
• x/perp/v2/keeper/msg_server.go (3 hunks)
• x/perp/v2/keeper/sudo.go (2 hunks)
• x/perp/v2/keeper/sudo_test.go (5 hunks)
• x/perp/v2/module/abci_test.go (4 hunks)
• x/perp/v2/types/msgs.go (1 hunks)
• x/sudo/cli/cli_test.go (1 hunks)

• x/perp/v2/keeper/msg_server.go
• x/sudo/cli/cli_test.go

wasmbinding/wasm.go (2)

• 13-20: The removal of the perpv2 parameter from NibiruWasmOptions and the corresponding update to the CustomMessageDecorator call are consistent with the PR's objective to migrate market creation functionality away from Wasm Binding.

• 29-33: The update to the CustomMessageDecorator call, removing the perpv2 parameter, aligns with the PR's objective to remove Wasm Binding from market creation.

wasmbinding/message_plugin.go (3)

• 12-15: The removal of the "perpv2keeper" import is consistent with the changes made to remove Wasm Binding from the market creation process.

• 20-25: The removal of the "Perp" field from the CustomMessenger struct aligns with the PR's objective to remove Wasm Binding from market creation.

• 85-94: The removal of the "perpv2" parameter from the CustomMessageDecorator function signature is consistent with the removal of Wasm Binding from market creation.

wasmbinding/exec_perp_test.go (3)

• 10-15: The removal of the wasmbinding package import is consistent with the changes made to remove Wasm Binding from the market creation process.

• 30-35: The removal of the exec field from the TestSuitePerpExecutor struct aligns with the PR's objective to remove Wasm Binding from market creation.

• 113-117: The removal of the s.exec initialization from the SetupSuite function is consistent with the removal of Wasm Binding from market creation.

x/perp/v2/module/abci_test.go (2)

• 28-33: The introduction of the adminUser variable in the TestSnapshotUpdates and TestEndBlocker functions is likely related to the new permission checks for market creation.

• 47-47: The usage of the adminUser variable in the CreateMarket function call within the runBlock function aligns with the PR's objective to incorporate the new adminAccount parameter.

x/perp/v2/integration/action/market.go (2)

• 163-170: The addition of the adminAccount field to the createPool struct and its usage in the Do method extends functionality related to administrative account handling.

• 180-187: The update to the CreateMarket function's signature to include the adminAccount parameter aligns with the PR's objective to enhance administrative control.

x/perp/v2/keeper/sudo.go (1)

• 70-87: > Note: This review was outside the patches, so it was mapped to the patch with the greatest overlap. Original lines [76-104]

The changes to the CreateMarket function, including the addition of the adminAccount parameter and permission checks using SudoKeeper, align with the PR's objective to enhance administrative control.

x/perp/v2/types/msgs.go (2)

• 468-478: The ValidateBasic method for MsgCreateMarket correctly checks for the validity of the Pair, SqrtDepth, and PriceMultiplier fields. It ensures that SqrtDepth and PriceMultiplier are positive, which is a logical requirement for market creation parameters.

• 481-487: The GetSigners method implementation for MsgCreateMarket is standard and follows the Cosmos SDK pattern for retrieving the signer's address from the message sender field. It correctly panics if the address cannot be parsed, which is appropriate for a signer retrieval method.

app/app.go (1)

• 119-124: The changes to the GetWasmOpts function reflect the PR's objective to remove Wasm Binding options for the perp module. The removal of nibiru.PerpKeeperV2 is consistent with the migration to MsgCreateMarket and does not appear to introduce any issues.

proto/nibiru/perp/v2/tx.proto (3)

• 58-58: The addition of the CreateMarket RPC method to the Msg service is consistent with the PR's objective to migrate market creation functionality. Ensure that corresponding server-side implementation and client-side usage are updated to handle this new RPC method.

Verification successful

---

The server-side implementation and client-side usage of the CreateMarket RPC method have been verified through the provided output. The method is implemented in the msg_server.go file and used in various test and keeper files, indicating that the necessary updates to handle this new RPC method are in place.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify server-side implementation of CreateMarket
rg --type proto "CreateMarket\(MsgCreateMarket\) returns \(MsgCreateMarketResponse\)" -A 3 -B 3

# Verify client-side usage of CreateMarket
rg --type go "CreateMarket" -A 3 -B 3

Length of output: 26161

* 466-490: The `MsgCreateMarket` message definition includes all necessary fields for market creation. However, the `market` field is marked as nullable, which may be intentional to allow for optional market parameters. Confirm that the business logic correctly handles cases where the `market` field is not provided.

Verification successful

---

The CreateMarket method in sudo.go checks if the args.Market is nil and if so, it initializes the market with a default value using types.DefaultMarket(pair). If args.Market is not nil, it uses the provided Market object. This confirms that the business logic does handle cases where the market field is not provided by initializing a default market.

• The nullable market field in the MsgCreateMarket message is correctly handled in the business logic.
• If the market field is not provided, a default market is initialized.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify handling of nullable market field in MsgCreateMarket
rg --type go "MsgCreateMarket" -A 10 -B 10 | rg "market"

Length of output: 1075

---

---

Script:

#!/bin/bash
# Examine the CreateMarket function in msg_server.go for handling of the nullable market field
rg "func \(.*CreateMarket" x/perp/v2/keeper/msg_server.go -A 30

Length of output: 577

---

---

Script:

#!/bin/bash
# Examine the CreateMarket method within the Sudo object for handling of the nullable market field
rg "func \(.*Sudo.*CreateMarket" x/perp/v2/keeper/ -A 30

Length of output: 58

---

---

Script:

#!/bin/bash
# Broad search for the CreateMarket method to handle the nullable market field
rg "func \(.*CreateMarket" x/perp/v2/keeper/ -A 30

Length of output: 2743

* 492-492: The `MsgCreateMarketResponse` message is currently empty. If this is intentional and no data is expected to be returned, this is acceptable. Otherwise, consider adding fields to the response message that would be useful to clients, such as an identifier for the created market or a confirmation status.

Verification successful

---

Based on the search results, the MsgCreateMarketResponse message is intentionally empty, and the function CreateMarket in msg_server.go returns an empty response. This suggests that the current implementation is as intended, and no additional fields are expected in the response message at this time.

• The MsgCreateMarketResponse struct is defined without fields, and the associated methods are standard for protocol buffer messages.
• The CreateMarket function returns an empty MsgCreateMarketResponse, which is consistent with the message definition.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify if the MsgCreateMarketResponse should contain fields
rg --type go "MsgCreateMarketResponse" -A 3 -B 3

Length of output: 8444

x/perp/v2/keeper/sudo_test.go (7)

• 106-106: The addition of adminUser as a parameter to the CreateMarket function call is consistent with the PR's objective to enhance permission checks for market creation. Ensure that the adminUser is properly set up in the test environment and has the necessary permissions.

• 116-116: The adminUser parameter is correctly passed to the CreateMarket function call, which is expected to fail due to an invalid oracle pair. This is in line with the PR's objectives.

• 124-124: The adminUser parameter is added to the CreateMarket function call, which is expected to fail due to a negative price multiplier. This change is consistent with the PR's objectives.

• 132-132: The adminUser parameter is added to the CreateMarket function call in a successful test case. This aligns with the PR's objectives to require admin permissions for market creation.

• 153-153: The adminUser parameter is added to the CreateMarket function call in a test case where the market already exists. This is consistent with the PR's objectives and the test case's intent to validate the error condition.

• 164-164: The adminUser parameter is added to the CreateMarket function call in a test case where the market is closed and then recreated. This aligns with the PR's objectives to require admin permissions for market creation.

• 181-186: The adminUser parameter is added to the CreateMarket function call in a test case designed to fail when the creator is not a sudoer. This is a critical test for verifying permission checks and aligns with the PR's objectives.

x/perp/v2/keeper/amm_test.go (4)

• 163-173: The addition of adminUser and the removal of EnableMarket from ArgsCreateMarket align with the PR objectives to migrate market creation functionality. Ensure that the adminUser is properly authorized and that all necessary permission checks are in place.

• 236-246: Similar to the previous comment, the addition of adminUser and the removal of EnableMarket from ArgsCreateMarket are consistent with the PR objectives. However, ensure that the adminUser is being used correctly in all contexts where market creation is tested.

Verification successful

---

The search results indicate that adminUser is indeed used in various test files within the x/perp/v2 directory. The usage of adminUser is consistent with the context of market creation and other market-related operations such as CloseMarket. The variable adminUser is assigned using sdk.AccAddressFromBech32(testutil.ADDR_SUDO_ROOT) and is then passed as a parameter to functions like CreateMarket and CloseMarket.

Based on the information provided by the script output, it appears that adminUser is being used correctly in the contexts where market creation is tested, as well as in other market operations. This aligns with the PR objectives and the review comment, which suggested verifying the correct usage of adminUser in market creation tests.

Therefore, the review comment is consistent with the codebase, and the verification process has not revealed any issues with the usage of adminUser.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that adminUser is being used correctly in all contexts where market creation is tested.
rg --type go 'CreateMarket' | xargs -I {} grep -Hn 'adminUser' {}

Length of output: 11714

---

---

Script:

#!/bin/bash
# Search for the usage of `adminUser` in the context of `CreateMarket` calls within Go files.
rg --type go -C 10 'CreateMarket\(.*adminUser' 

Length of output: 48

---

---

Script:

#!/bin/bash
# Broaden the search to find any usage of `adminUser` within Go files.
rg --type go 'adminUser'

Length of output: 2344

* 446-456: The changes in this test function are consistent with the PR's objectives. The `adminUser` is being set up for market creation, which is a key part of the new functionality. Ensure that the `adminUser` has the expected permissions and that the market creation process is robust.

Verification successful

Let's generate a new script to properly search for the usage of adminUser in the context of CreateMarket using rg.

---

Let's generate a new script to search for occurrences of adminUser in the codebase to understand how it is being used, which might give us clues about its permissions related to market creation.

---

The search results show multiple occurrences of adminUser being used in various test files. The adminUser is created using sdk.AccAddressFromBech32 with an address that seems to be associated with a root or admin-level permission, as indicated by ADDR_SUDO_ROOT. This user is then passed to functions like CreateMarket and CloseMarket, suggesting that adminUser is indeed intended to have administrative permissions for market operations.

Based on the context provided by the search results, it appears that the adminUser is set up with the expected permissions for market creation and management in the test environment. This aligns with the PR's objectives and the review comment's approval.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that adminUser has the expected permissions for market creation.
rg --type go 'CreateMarket' | xargs -I {} grep -Hn 'adminUser' {}

Length of output: 11714

---

---

Script:

#!/bin/bash
# Search for the usage of `adminUser` in the context of `CreateMarket` using ripgrep
rg 'CreateMarket\(.*adminUser' --type go

Length of output: 42

---

---

Script:

#!/bin/bash
# Search for occurrences of `adminUser` in the codebase
rg 'adminUser' --type go

Length of output: 2344

* 474-484: The changes here are similar to the previous test functions, with the `adminUser` being added for market creation. It is important to verify that the `adminUser` is used consistently and correctly across all test cases.

Verification successful

Let's adjust the script to correctly search for the usage of adminUser in the context of CreateMarket calls within Go files. We will use rg to search for CreateMarket and then directly filter for adminUser within the same command.

---

Let's broaden the search to capture any usage of adminUser within a wider context of CreateMarket calls.

---

Based on the new context provided by the shell scripts, we can see that adminUser is indeed used in the context of CreateMarket calls within various test files. The output shows that adminUser is assigned from sdk.AccAddressFromBech32(testutil.ADDR_SUDO_ROOT) and then passed to the CreateMarket function in multiple instances across the sudo_test.go and amm_test.go files.

This confirms that the adminUser is used consistently and correctly across all test cases where CreateMarket is called, as per the review comment's request for verification.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that adminUser is used consistently and correctly across all test cases.
rg --type go 'CreateMarket' | xargs -I {} grep -Hn 'adminUser' {}

Length of output: 11714

---

---

Script:

#!/bin/bash
# Search for the usage of `adminUser` in the context of `CreateMarket` calls within Go files.
rg --type go 'CreateMarket\(.*adminUser' -C 3

Length of output: 47

---

---

Script:

#!/bin/bash
# Broaden the search for the usage of `adminUser` in the context of `CreateMarket` calls within Go files.
rg --type go -C 10 'CreateMarket' | rg 'adminUser'

Length of output: 1140

CHANGELOG.md (1)

• 73-73: The changelog entry for PR feat(perp): move create market from Wasm Binding to MsgCreateMarket as part of #1642  #1761 is correctly added under the "Dapp modules: perp, spot, etc" section, adhering to the changelog standards.